April 1996

Installing the NCSA WWW Server

By Al Alexander

For the last several years, the Internet and the World Wide Web have been the most publicized and possibly the most exciting part of computing. It seems that every company, large and small alike, is putting its corporate information on the Web.

The technology has recently spread even further to create corporate intranets--in-house Web servers that store information that can be accessed by employees on internal LANs. Intranet information includes employee manuals, telephone directories, policy manuals, engineering documents, and much more. The Internet and intranets promise to become even more exciting as technologies such as VRML and Java bring animation to the Web.

Since the inception of the Web, NCSA (National Center for Supercomputing Applications at the University of Illinois) and CERN (Center for European Particle Physics Laboratory) have created free, public domain Web server software known as HTTP (HyperText Transfer Protocol) daemons. These HTTP daemons allow schools, corporations, and government agencies to create their own Web servers on UNIX platforms. As the Web has evolved over the last two years, NCSA's Web server software has won the battle for the public domain HTTP daemon Web server, offering more features and functionality than the CERN version.

In this article, we'll explore the process of acquiring NCSA's HTTPD Server software and installing it on a Solaris 2.4 system. In the process, we'll set up a fictitious Internet Web site that we'll call www.alexander.com.

Obtaining the NCSA HTTPD Server software

The first part of the installation process is obtaining the NCSA HTTPD Server software. The Server software can be obtained directly from NCSA via the Internet.

The easiest way to retrieve the file is to point your Web browser (i.e., Netscape Navigator, Mosaic, or a similar product) to the URL http://hoohoo.ncsa.uiuc.edu/docs/setup/PreCompiled.html. This URL displays a self-explanatory Web page that allows you to download the entire NCSA Server software distribution. This distribution includes binary executables and necessary subdirectory structures but, unfortunately, no installation instructions.

At the time of this writing, the most recent version of the NSCA HTTPD Server software is 1.5a. It's available for the following Sun platforms:

Putting the Server software in an appropriate directory

The default directory location for the Server distribution is /usr/local/etc/httpd. You can change this default as desired, but it fits our directory tree structure very well, so we'll install it at that location.

The file that you'll download from NCSA's Web site has been tared and compressed. For the Solaris 2.4 x86 environment, the file we downloaded, named httpd_1.5a-export_ solaris2.4_x86.tar.Z, was 498,103 bytes, or about 0.5MB.

After downloading the file, place it in a directory named /usr/local/etc. If you don't have this directory already, create it as follows:

mkdir -p /usr/local/etc

Next, copy the file to that directory, and then make that your current working directory:

cp <filename> /usr/local/etc

cd /usr/local/etc

As we mentioned, the distribution is tared and compressed. Therefore, the next step is to uncompress the file:

uncompress <filename>

This expands the x86 distribution to a 1,130,496-byte file. Next, use the tar command to extract the tar archive:

tar xvf <filename>

This command extracts all of the NCSA HTTPD Server files into a subdirectory named httpd_1.5a-export. The last step in the installation is to rename that directory to the default name httpd:

mv httpd_1.5a-export httpd

The NCSA distribution is now installed in the default location, /usr/local/etc/httpd. Move into the httpd directory and list the files in that directory:

cd httpd

ls -al

The complete distribution includes not only all of the necessary binaries and configuration subdirectories and files, but also the source code for the HTTPD Server. If you're a C programmer with a C language compiler, you'll find this code valuable if you want to make changes to the actual binary.

The directory /usr/local/etc/httpd is called the ServerRoot directory. At a minimum, the files and directories shown in Table A should be in the ServerRoot directory.

Table A

File or Directory/Description

httpd NCSA HTTPD Server binary executable file

./conf Configuration file subdirectory

./logs Server log files subdirectory

./support Various support-related programs subdirectory

./cgi-bin Common Gateway Interface files subdirectory

The logs directory didn't exist in the distribution, so you must create it manually:

mkdir logs

Other files may also be in your ServerRoot directory, including BUGS, CHANGES, COPYRIGHTS, CREDITS, a Makefile, and a README. You may want to view these files to understand more about the distribution contents.

Modifying the Server configuration files

You can configure the NCSA HTTPD Server in three different ways:

1. At compile time by modifying the C language source code

2. Through startup configuration files

3. Through run-time configuration

The first option requires a C language compiler and is rather inflexible when you want to make changes to the Server as it's running. The third option is typically used to control access to portions of directory trees.

The second option, using configuration files, is probably the most common method of configuring the NCSA Server. Throughout the remainder of our discussion, we'll examine the second method and show you how to configure the NCSA Server by modifying its startup configuration files.

The conf subdirectory contains the Server configuration files. When the Server daemon starts, it examines three files in this directory, as shown in Table B.

Table B

Filename/Description

access.conf Access control file

httpd.conf Server configuration file

srm.conf Resource configuration file

When you look in your conf subdirectory, you'll notice that these three files exist in the r subdirectory, but they're followed by the extension -dist. These files are sample files that come with the distribution.

Copy these three -dist files to the names shown above, and then edit them to customize them for our environment:

cd conf

cp access.conf-dist access.conf

cp httpd.conf-dist httpd.conf

cp srm.conf-dist srm.conf

By copying these files instead of renaming them, we keep the original files as a future reference.

Each of the three files contains a fair number of comments. Commented lines are those lines that begin with the # symbol. We'll look first at the access.conf global access configuration file.

access.conf

The file access.conf is the global configuration file. This file contains only a few variables, and if you put your Server files in the default locations, the defaults for these variables will be fine.

Please note that if you decide to put your Server or your Home Page documents in alternate directories, you'll need to change the two Directory entries in this file to reflect your specific locations. Because we're installing the Server files in the default locations, no changes are required to the access.conf file.

httpd.conf

The main Server configuration file is httpd.conf. When it starts, the Server daemon looks in this file to determine important information, such as the TCP/IP port to run on, which user and group will own the Server daemon, etc.

For most basic HTTPD Server installations, many of the default values will work just fine. The few options that may need to be changed initially are shown in Table C.

Table C

Variable Name/Default Value

ServerName <none>

ServerAdmin you@your.address

ServerRoot /usr/local/etc/httpd

User nobody

Group -1 VirtualHost

You should set the ServerName variable to the TCP/IP name of your UNIX server in your /etc/hosts file (or NIS database). Since we're setting up a site named www.alexander. com, we'll use the following statement:

ServerName www.alexander.com

You should change the variable Server-Admin to the E-mail address of the person administering your Web site. For the purposes of this article, we'll assume that the Web administrator's username is al, so you should set the ServerAdmin variable as follows:

ServerAdmin al@www.alexander.com

As we mentioned, ServerRoot is the root, or top, level directory of the HTTPD Server files and directories. Because our Server is installed in the default location, there's no need to change this variable. Please note that if the Server was installed into another directory, such as /var/ncsa_httpd, you'd need to modify the ServerRoot variable as follows:

ServerRoot /var/ncsa_httpd

The User and Group variables represent the owner of the Server daemon while it's running on the computer system. Although the root user must start the HTTPD Server, the ownership of the child processes changes to the User and Group values specified in the httpd.conf file. This is done to enhance security by allowing you to make the daemon run with fewer privileges.

The User and Group default values are nobody and -1, respectively. These are good choices, but a minor change may be required. On a typical Solaris machine, a username of nobody already exists, so no change is required there.

A group named nobody also exists, but the default group ID for the group nobody on Solaris 2.4 is 60001, not -1. Therefore, you need to change the Group variable to the name nobody instead of using the number -1, as shown below:

User nobody

Group nobody

The VirtualHost variable (the last few lines of the file) is configured to allow your Server to respond to client requests for multiple hostnames. For instance, it's possible to configure your Server to respond not only to requests for www.alexander.com, but also for other domain names, such as www.acme.com and www.foo.com.

This option is typically used by Internet service providers who sell Internet access to corporations, but not by corporations, schools, or government agencies. The best thing to do with the VirtualHost variable is to comment out the lines that configure it:

# <VirtualHost 127.0.0.1 Optional>

# DocumentRoot /local

# ServerName localhost.ncsa.uiuc.edu

# ResourceConfig conf/localhost_srm.conf

# </VirtualHost>

One final comment on the httpd.conf file: Please note that the HTTPD Server listens on TCP/IP Port 80 by default. This is the default port that Internet browsers such as Netscape call on when looking for a Web server. The HTTPD Server must be configured to listen on the same port that the browser is calling, so we'll leave the Server at port 80. (If you change the port number, no one will be able to access your Web server without changing their Web browser software.)

srm.conf

The file srm.conf configures the server's resources. This configuration file defines the name space that users of your Server can see. You may need to change several of the default variables in this file to configure your site. These variables are shown below:

DocumentRoot /usr/local/etc/httpd/htdocs

Redirect /HTTPd/http://hoohoo.ncsa.uiuc.edu/

The DocumentRoot variable defines the location of your home page documents. By default, your initial home page document--index.html--and the remainder of your HTML documents must be in the /usr/local/etc/httpd/htdocs directory and subdirectories of that directory. If you want to keep your home page documents in another location, you'll need to change the DocumentRoot, Alias, and ScriptAlias variables to reflect that location.

You don't need the Redirect variable for an initial installation, so you can comment it out:

# Redirect /HTTPd/http://hoohoo.ncsa.uiuc.edu/

Because we're configuring our server to work in the default location, we'll use the default directory. First, create the htdocs directory in the /usr/local/etc/httpd directory:

mkdir /usr/local/etc/httpd/htdocs

Let's create a home page!

Now we nearly have the Web server configured. Before we proceed to the last step, that of running it, let's create a home page. To do so, go to the DocumentRoot directory by typing

cd /usr/local/etc/httpd/htdocs

Now, using vi (or a similar editor) create a text file named index.html. Make sure it contains the following text. It's very important that you copy this text exactly.

<HTML>

<TITLE>My Home Page</title>

<h1>Welcome to my Home Page!</h1>

<h2>Documents on the system include:</h2>

<ul>

<li><a href="http://www.alexander.com/bio.html">

A description of the site manager.</a>

<li>Watch for new documents in the future!

</html>

Now, in our fictitious example, any time a user points a browser at the URL http://www.alexander.com, he or she will receive this document as the home page. After you've created your home page, return to the conf directory to finish changing the srm.conf file:

cd ../conf

Starting the HTTPD Server daemon

Now that you've properly modified the configuration files, you can start the HTTPD Server daemon in one of three different ways:

For performance reasons, you shouldn't start the server from the /etc/inetd.conf file. There's a lot of overhead involved in starting the HTTPD daemon in this manner that slows the response time under a heavy load.

Therefore, we'll initially start our server from the command line. Once it's working, we'll create a simple shell program that will start the server every time the computer boots into multi-user mode.

The httpd file in the ServerRoot directory (/usr/local/etc/httpd/httpd) is the server binary executable file. When this file runs, it reads the configuration files in the conf subdirectory and begins running as a daemon process. Usage options for starting the HTTPD daemon from the command line are shown in Figure A.

Figure A

httpd Usage:

httpd [-d directory] [-f file] [-v]

-d directory specify an alternate initial ServerRoot directory

-f file specify an alternate Server Configuration file (httpd.conf)

-v display version information.

Because the server is installed in the default location, no options are required at the command line. Therefore, to start the server, type

/usr/local/etc/httpd/httpd

You shouldn't see any error messages when the server starts. If you do see messages, record those messages and carefully review the previous steps.

Also, note that the server automatically runs in the background. You don't need to use the & character after the command to run it in the background.

If everything is working properly, you should be able to identify six processes running on your computer waiting for client requests, as shown in Figure B. Running the command in Figure B should return seven output lines. (The last output line in Figure B shows the process that's running the grep command that's filtering out the processes dealing with httpd.)

The output displays the process you created, process ID (PID) 491, owned by root, and five other processes, owned by the user nobody. The five processes owned by nobody are child processes of the parent process, PID 491.

You created five child processes because the variable StartServers is set to 5 in the httpd.conf file. These five processes listen on port 80 for client requests and respond to those requests as they occur.

The NCSA HTTPD Server is now running on your Solaris server. To verify that an end user can actually see your home page, you'll need access to another computer on your TCP/IP network that has a browser, and you must point that browser at your new Web server.

In our fictitious example, the server is named www.alexander.com. On another computer on my network that has a browser, we'd enter the URL http://www.alexander. com. The home page document we created above would appear. Figure C shows how Netscape would display the home page for www.alexander.com.

Starting the server automatically at boot time

With the server starting properly from the command line, the last thing you need to do is to start the server processes automatically at boot time. You can easily accomplish this by creating a shell program and putting that shell program in the /etc/rc2.d directory.

Figure D shows a simple shell program to accomplish this task. The shell program is named S99ncsa_httpd, which is consistent with the naming structure in the /etc/rc2.d directory.

Figure D

#!/bin/sh

#

# PROGRAM: S99ncsa_httpd

#

# PURPOSE: Start the NCSA HTTPD Server daemon at boot time.

#

#

# Run the NCSA HTTPD Server command:

#

/usr/local/etc/httpd/httpd

#

# Check the Exit Status of the previous command.

# If the status = 0, it started ok.

# If the status != 0, it did not start correctly.

#

STATUS=$?

if [ $STATUS -eq 0 ]

then

echo "NCSA HTTPD Server Daemon started successfully."

else

echo "The NCSA HTTPD Server Daemon did not start properly."

fi

VERY IMPORTANT NOTE: Make sure you test this shell program from the command line before putting it in the /etc/rc2.d directory and rebooting the computer. If there's an error in this file and the computer can't get past it during the boot process, your computer could hang at boot time!

First, create this file in the /tmp directory. Then kill the old server processes by killing the parent process (PID 491 in our example):

kill 491

(To find the parent PID #, just look at the output of the ps -ef | grep httpd commands, and look for the line starting with root. The number following root is the PID of the parent's process. Killing this process will automatically kill the child processes as well.)

Now that you've stopped the Web server, you can test the startup shell script by typing the following command:

sh ./S99ncsa_httpd

If the server is started properly, you'll see the message NCSA HTTPD Server Daemon started successfully. If it fails, or if it hangs for any reason, you'll need to begin the debugging process.

You can verify that the server is running by reissuing the ps -ef | grep httpd command and verify that it shows a parent process and five child processes. If the startup shell script works successfully, copy it to the /etc/rc2.d directory:

cp /tmp/S99ncsa_httpd /etc/rc2.d

The Solaris operating system will now automatically run this script every time your computer is booted to run state 2 (the normal multi-user mode).

Conclusion

The Internet and intranets have helped to bring an enormous amount of information to end users in the last few years. Configuring the NCSA Web Server is a relatively simple and straightforward process that can help your organization achieve further information distribution goals that can benefit everyone at your company.

Alvin J. Alexander is an independent consultant specializing in UNIX and the Internet. He has worked on UNIX networks to support the Space Shuttle, international clients, and various Internet Service providers. He provided UNIX and Internet training to over 400 clients in the last three years.


[Return to Index for Inside Solaris - April 1996 Issue]

Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.

Inside Solaris is a publication of The Cobb Group.
1-800-223-8720